簡易的なAWSアカウントへの緊急アクセス経路(Breakglass)を作成する

川原征大

2023.08.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

緊急時にAWSアカウントへアクセスできる経路(Breakglass) を作ってみます。 IAM Identity Center 、およびIAMロールを使って実現します。

以降でアーキテクチャ選定、設計・構築について記載します。

前提

今回は AWS Organizations を利用したマルチアカウント環境での緊急アクセス経路を想定します。

"緊急時" というのは色んな解釈ができるため、もう少し範囲を狭めておきます。本ブログでは AWSアカウント上で何か障害が起きた際に、「 通常の構築/運用担当者がアクセスできない状況 」を想定します。そのときに、他のメンバー(例: セキュリティチーム)が緊急でアクセスできる経路を作成します。

また設計にあたり、以下AWSブログやホワイトペーパーを参考にしています。

アーキテクチャ選定

緊急アクセス経路の選定ポイントとして、 3つの分類を記載しました。それぞれ考えていきます。

認証基盤どれにする？

緊急アクセス経路で使う認証情報を考えます。 IAMユーザーと IAM Identity Center(SSO)ユーザーが候補です ¹ 。

それぞれのメリット/デメリットを簡単に記載します。

	メリット ?‍	デメリット ☔
IAMユーザー	IAM Identity Center 障害時にも使える	余分に認証情報やグループを管理
IAM Identity Center ユーザー	グループ・アクセス管理が楽	IAM Identity Center 障害への考慮

IAMユーザーを使う最大のメリットは、グローバルサービスであることです。 IAM Identity Center はリージョンサービスなので、リージョン単位の障害が起きた際には、使えなくなる可能性があります。

一方、管理コスト面では IAM Identity Center の方が楽です。 IAM Identity Center 側で「通常のアクセス経路」と「非常時のアクセス経路」を併せて管理できます。 IAMユーザーを作る場合は、余分に認証情報やグループ管理が必要です。

アクセス方法どうする？

どのように対象のAWSアカウントへアクセスするかを決めます。候補は「直接ログイン」もしくは「スイッチロール」です。

それぞれのアクセスイメージは以下のとおりです。

	メリット ?	デメリット ☔
直接ログイン	アクセスが直感的	スケールが手間
スイッチロール	スケールが容易	スイッチロールが手間

スイッチロールはいわゆる Jumpアカウント構成です。

– 画像: AWSにおけるマルチアカウント管理の手法とベストプラクティス(PDF) | AWS Summit

スイッチロールは各AWSアカウントへIAMロールを展開するのみなので、スケールが容易です。

一方で直接ログイン、スケールは少し面倒です。特にIAMユーザーを使う場合は、AWSアカウントが増えるたびにIAMユーザーを新規作成しないといけません。

権限昇格を仕組み化する？

Breakglass アクセスの定義を色々と調べていると、「非常時に承認フローを経て、アクセス権を自動昇格」のような記載が多いです。ただ、今回は「簡易的」ということで、仕組み化しない選択肢も考慮します。

	メリット ?	デメリット ☔
仕組み化する	厳密なアクセス管理	管理・運用コストが高い
仕組み化しない	管理・運用コストが低い	不用意に使われるリスク

前提として「緊急アクセス経路の使用」を詳細にロギングすることは必須です。

仕組み化しない場合は、管理者の把握外で使われるリスクに注意します。例えば「緊急アクセス経路の使用」を通知する環境を用意しておくと安心でしょう。

また、IAM Identity Center を使って権限昇格を仕組み化する場合は、 AWSソリューション(TEAM)を活用しても良さそうです。以下TEAMの参考ブログです。

AWS IAM Identity Center において一時的なアクセス許可を与える仕組みを提供する Temporary Elevated Access Management (TEAM) ソリューションを試してみた | DevelopersIO

本ブログのアーキテクチャ

以上の選定ポイントをもって、本ブログでは以下アーキテクチャで進めます。

IAM Identity Center ユーザーを活用する
- 認証認可を集中管理したいため
- IAM Identity Center はリージョナルサービスであり、十分な可用性があると判断
スイッチロールを活用する
- スケールが容易なため
権限昇格を仕組み化しない
- 仕組み化する場合の「仕組みのメンテナンス」や「フローの周知、徹底」コストが重たい
- 最低限、緊急アクセス使用を管理者が把握できるように、整備することで許容する

設計〜構築

全体構成は以下のとおりです。

それぞれ詳細を以降で説明します。

AWSアカウント構成

Breakglassアカウントを作成します。

Breakglassアカウントから各メンバーアカウントへアクセスできるように、以降の IAM Identity Center を構成していきます。

IAM Identity Center 構成

IAM Identity Center にて緊急アクセス用のグループを作成します。そのグループに Breakglassアカウントへのアクセス割当を作成します。

割当で使用する許可セット(BreakglassAccess)には「スイッチロールできるポリシー」を設定します。具体的には以下のようなポリシーです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "*"
    }
  ]
}

IAMロール構成

各メンバーアカウントにIAMロール(Breakglass_Admin)を配置します。この配置は CloudFormation StackSets などで自動化しておくと良いでしょう。

ロールの信頼関係ポリシーを適切に設定します。具体的には Breakglass アカウントからの AssumeRole を許可するポリシーです。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::${BreakglassアカウントID}:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

ロールのポリシーとして AdministratorAccess を付与しておきます。